The invention relates, in general, to a system and method for dynamically managing the transport of internet protocol-based traffic between user terminals and external xe2x80x98gatewaysxe2x80x99, and is particularly, but not exclusively, applicable in the context of a satellite system having a multiplicity of user beams accessible from several gateways of an internet-type terrestrial domain.
In modern telecommunication systems, information (such as coded speech and data) may be transferred using a variety of techniques across a plethora of system architectures, including satellite links, internet domains and broadband networks. With demand for constantly increasing levels of service, communication technologies are embracing integration of systems to provide enhanced architectures that synergistically benefit from efficient use of transport mechanisms during successive environments. However, the interworking of differing communication technologies often leads to implementation problems, particularly associated with the inability of different systems to realy, in a contiguous and seamless fashion, control information in a usable form. There are clearly mechanisms that allow for direct translation, or the re-packaging of information, but with integration of certain communication architectures and protocols in there embryonic stages the issues of providing full interworking are yet to be fully appreciated or addressed.
In multimedia broadband satellite systems, there is a necessity to transport traffic between user terminals and external gateways. There gateways are essentially router-based interfaces to either an internet service provider (ISP) via the internet or a private network (such as a local area network, LAN) supporting, for example, internet protocol (IP) traffic. As regards interfacing between external terrestrial networks and a satellite network running IP-based protocols (both over the ground and in satellite sagments thereof), such interfacing requires the exchange of interior and exterior routing information. Traditionally, large scale networks, like the Internet or other private carrier network, have to date used specifically developed routing protocols, such as the border gateway protocol (BGP4) discussed in the outline article xe2x80x9cA Border Gateway Protocol (BGP)xe2x80x9d by K Lougheed et al, June 1989 (available at http://sunsite.org.uk/rfc/rfc1105.txt). Indeed, BGP provides an interworking capability between the internet and a satellite gateway.
As will be appreciated, each gateway therefore provides an ingress/egress point for a satellite link, thus providing the interface to terrestrial networks, whereas each terminal connects user (e.g. computer) equipment to the satellite link in a dial-on-demand fashion (i.e. connectivity when requested). Gateways may be interconnected. As regards a typical geo-stationary satellite, terminally circular geographic coverage area (or xe2x80x98footprintxe2x80x99) in which designated service are provided.
Recent progress in swithching capabilities of satellite systems has enabled mappings between user beams (UBs) to gateways to follow a one-to-many basis (as well as the original one-to-one basis). In other words, connections to multiple gateways from the same user beam and multiple user beams from one gateway are now readily supportable, although there is usually some form of default set-up where a particular user beam is always associated with a particular gateway. The mapping of such user beam to gateway connection information (known as the xe2x80x9cconnectivity matrixxe2x80x9d) is held by a network controller that operationally managers connections through the system. However, the satellite payload does not utilise any information concerning bandwidth availability or congested data routes and so it is not possible to determine the optimum (or xe2x80x9cleast castxe2x80x9d through the satellite network in terms of the route set-up overhead) data route. Furthermore, connectivity requirements within a satellite system are often in a state of flux (changing from hour to hour), as a consequence of changing service demands, fault conditions and system operator decisions.
Decision between separate ISPs (or network providers) to use policy-based routing to enforce routing decisions based on the use or avoidance of selected inter-autonomous system (ASs) as transit networks, is known as a xe2x80x9cpeering agreementxe2x80x9d. Moreover, in order to achieve a situation where ingress bound IP packets can have an optimum route it is necessary to have peering agreements with internet service providers (ISPs). Such agreements are provided by BGP policy-based routing techniques (discussed in more detail below). The use of policy-based routing is understood to help avoid congestion within a satellite network as the policy-based routing distributes points of ingress of IP packets across a large number of gateways, rather than just restricting access to a single or small number of gateways.
In modern satellite networks, difficulties are often experienced as a result of xe2x80x98internet bottlenecksxe2x80x99 caused, for example, by: i) congested routers providing access between multiple inter-autonomous systems; ii) the set-up of links that attempt to avoid long haul terrestrial routes. Consequently, there is a need to identify and utilise data paths that bypass such difficulties, but which are preferably optimised in terms of shortest route length. The latter criterion is important when one considers that if an IP data packet has a longer route to traverse, then there is both an increased chance of the IP packet being lost and second, that an unacceptably long delay may be introduced into the path. Of course, in view of the distances travelled by signals in a satellite system, some delay is unavoidable (but excessive delays render services, such as voice calls unacceptably fractured and hence incoherent). It will be understood that, in this particular context, route length may be determined by the number of hops or routes that process the packet, as well as absolute traversed distance.
In a multimedia broadband satellite system, it is known to have an element of on-board processing within a satellite payload. Such satellite systems generally have dynamically changing connectivity. This information is vital in determining both how network topology is represented at any one moment in time and also the correct xe2x80x9clink statexe2x80x9d for the connection. However, upon transgressing a boundary between the satellite system and the terrestrial network, dynamically changing traffic loading within the satellite system is not effectively relayed into the terrestrial network using BGP, with the border gateway (routing) protocol only providing policy management routing without any indication of optimised route selection.
BGP is an inter-autonomous system routing protocol that requires considerable manual intervention in order that its policy-based routing decisions work correctly. Often, manual changes are required to rectify incorrect policy decisions. Thus, BGP is reliant upon manual updates to maintain its correct function and, clearly, it is not dynamically interactive to other network changes. Even thought some vendor platforms have sufficient intelligence to handle some forms of automatic distribution of configuration information, BGP is still an exception to the rule and is, in fact, reliant on manual configuration to notify and update the distribution of internal routes (within an IP-based network) in order to advise external systems elements. Manual configuration is inefficient in terms of both time and expense). In operation, BGP essentially only propagates a gateway address through the interconnected network that indicates one of a number of paths to a satellite user beam. BGP is, in fact, unable to differentiate between different routes/paths and so in unable to advise, select or otherwise route a packet of data (or the like) through a link having, say, the largest bandwidth, shortest distance, link quality, the level of congestion at a gateway, efficiency, etc. In other words, BGP advertises user beam availability to internet service providers coupled through a terrestrial network to a gateway.
There are additional issues that need to be addressed for complete interworking of a satellite system with a terrestrial network. For example, in satellite networks, there is a high occurrence of xe2x80x9cuserxe2x80x9d connectivity available upon request. In this respect, connectivity can be considered to include dial-on-demand, with users paying for bandwidth as they use it and conceptually no permanent connections. For this reason, routes to individual subnets are only available when a user is (or a group of users are) actually connected even though such subnets are advertised by BGP as being available. In other words, present use of BGP can inaccurately reflect the connectivity within the satellite system.
Beam availability is another important factor that needs to be considered when using BGP to advertise internal satellite routes/links to external networks. Specifically, if there are no active connections within a user beam or if for some reason the gateway is inoperative, e.g. as a consequence of malfunction or interconnected wireline severance, than the routes available through that particular user beam should not be advertised as being available. However, the presently unresponsive nature of BGP inaccurately maintains an indication of route availability until manual alteration of BGP occurs; this clearly causes connection problems within the system as a whole and may result in lost calls and loss of revenue for the service operator.
As will therefore be appreciated, ideally, changes in availability with the satellite-terrestrial communication system should be advertised within the terrestrial network in a prompt, if not immediate, fashion. Moreover, the advertising of such routes should indicate whether a user beam or subscriber equipment is available (or not, as the case may be).
For completeness, it will be understood that, in operation, BGP uses a messaging protocol such as transmission control protocol/internet protocol (TCP/IP). Such a transmission protocol requires that two hosts form a transport protocol connection between one another and exchange messages to open and confirm the connection parameters. The initial data flow forms the entire BGP routing table, with incremental updates sent as the routing table changes. Furthermore, notification messages are sent in response to errors or special condition concerning the connection. If a connection encounters an error condition, a notification message is sent and the connection is optionally closed.
According to a first aspect of the present invention there is provided a method of routing information within a communication system having a wireline network interconnected through a plurality of gateways to a satellite system, the communication system having a network controller arranged to promote a route to the satellite system via a preferred gateway, the method comprising: generating BGP update instruction at the network controller, the BGP update instruction containing a metric altering a weighting of an identified route; sending the BGP update instruction to at least one of the plurality of gateways; and propagating the BGP update instruction into the wireline network from the at least one of the plurality of gateways.
Preferably, the metric is derived from a status of at least one gateway.
The metric may be determined from at least one of processing bandwidth; path availability information; and route congestion information.
In a preferred embodiment, the metric is associated with path attributes within the BGP update instruction.
The metric may be generated in response to receipt of a status report from at least one of the plurality of gateways. Furthermore, the status report may be generated in response to interrogation of said at least one of the plurality of gateways by the network controller.
It is preferred that the connectivity matrix is updated by the BGP update instruction.
In a particular embodiment, the plurality of gateways include a memory, and the method further comprises: updating the memory upon receipt of the BGP update instruction, the BGP update instruction providing a preferred route to the satellite system. Preferably, the BGP update instruction identifies an optimum route to the satellite system.
In a second aspect of the present invention there is provided a method of routine information within a satellite system having a connectivity matrix arranged to promote a data path via a preferred gateway providing a terrestrial interface to the satellite system, the method comprising: generating a border gateway protocol (BGP) update instruction from the connectivity matrix; and sending the BGP update instruction to terrestrial gateways to alter path selection undertaken thereby.
In this aspect, the method may further comprise generating a metric within the BGP update instruction altering a weighting of an identified route.
In a further aspect of the present invention there is provided a border gateway protocol (BGP) manager for control of routes through gateways between a terrestrial wireline network and a satellite system, the BGP manager comprising: means for generating a BGP update instruction containing a metric altering a weighting of an identified route; and means for sending the BGP update instruction to at least one gateway, thereby to promote to the terrestrial wireline network a route to the satellite system via a preferred gateway.
The BGP manager may further comprise: a connectivity matrix; and wherein the connectivity matrix is updated by the BGP update.
In another aspect of the present invention there is provided a network element of a wireline network coupled, in use, to a satellite communication system, the gateway comprising: a controller and associated memory co-operating to store communication paths to the satellite system, the controller responsive to BGP update instruction containing a metric altering a weighting of an identified route; and means for selecting a route into the satellite system in response to the BGP update.
The network element is typically one of a gateway and a router, and generally further comprises means for propagating the BGP update instruction into the wireline network.
Preferably, the network element has: means for determining an operational status of the network element; and means for communicating the status to a network controller to affect the metric.
In yet another aspect of the present invention there is provided a computer program product for a border gateway protocol management system having a network controller administering routing between a wireline network interfaced to a satellite communication system through a plurality of gateways, the computer program product comprising: code that directs the network controller to generate a BGP update instruction containing a metric altering a weighting of an identified route; code that directs the network controller to send the BGP update instruction to at least one of the plurality of gateways, whereby the network controller promotes a route to the satellite system via a preferred gateway; wherein the codes reside in a computer readable medium.
Advantageously, the present invention provides a system that enables a satellite network to maintain connectivity and utilise a least cost data route despite a slowly changing satellite connectivity matrix. Thus, optimum IP routing information for a satellite network may be provided for ingress bound packets to be delivered to the most appropriate gateway. Indeed, the present invention can be operated in a dynamic fashion in order to address bottlenecks that could potentially arise form identified paths, via preferred gateways, for particular user beams.
A border gateway protocol (BGP) management system dynamically determines an optimum or preferred data route from wireline networks into a satellite communication system. Multiple gateways provide access points to the wireline networks. The management system includes a connectivity matrix which processes information, such as bandwidth availability and route congestion, and then generate a BGP update that is communicated into at least one of the gateways. The BGP update promotes preferred gateways and so identifies a preferred access path to the satellite system. Specifically, the BGP update instruction contains a metric altering a weighting of an identified route data route, which metric effects path selection at a gateway receiving IP datagrams. The metric is derived from information pertaining to a connectivity matrix associated with the satellite system.